ADA Programming Guide/ADA Programming Guide.iso/ada_lrm/chap08.doc

Text File | 1996-01-30 | 39KB | 855 lines

                            8. Visibility Rules


The  rules  defining the scope of declarations and the rules defining which
identifiers are visible at various points in the text of  the  program  are
described  in this chapter.  The formulation of these rules uses the notion
of a declarative region.


References:  declaration 3.1, declarative region 8.1, identifier 2.3, scope
8.2, visibility 8.3

8.1  Declarative Region


A  declarative  region  is  a  portion  of  the  program  text.   A  single
declarative region is formed by the text of each of the following:


  -  A subprogram declaration, a package declaration, a  task  declaration,
     or  a  generic  declaration,  together with the corresponding body, if
     any.  If the body is a body stub, the declarative region also includes
     the corresponding subunit.  If the program unit has subunits, they are
     also included.


  -  An  entry  declaration  together   with   the   corresponding   accept
     statements.


  -  A record type declaration, together with a  corresponding  private  or
     incomplete  type declaration if any, and together with a corresponding
     record representation clause if any.


  -  A renaming declaration that includes  a  formal  part,  or  a  generic
     parameter  declaration  that  includes  either  a  formal  part  or  a
     discriminant part.


  -  A block statement or a loop statement.


In each of the above cases, the declarative region is said to be associated
with the corresponding declaration or statement.  A declaration is said  to
occur  immediately  within  a  declarative  region  if  this  region is the
innermost  region  that  encloses  the  declaration,   not   counting   the
declarative region (if any) associated with the declaration itself.


A  declaration  that occurs immediately within a declarative region is said
to be local to the region.  Declarations in outer (enclosing)  regions  are
said  to  be  global  to  an  inner (enclosed) declarative region.  A local
entity is one declared by a local declaration;   a  global  entity  is  one
declared by a global declaration.


Some  of  the  above  forms  of declarative region include several disjoint
parts (for example, other declarative items can be between the  declaration
of  a  package  and  its  body).   Each  declarative region is nevertheless
considered as a (logically) continuous portion of the program text.   Hence
if  any  rule defines  a portion of text as the text that extends from some
specific point of a declarative region to the end of this region, then this
portion is the corresponding subset of the declarative region (for  example
it does not include intermediate declarative items between the two parts of
a package).

Notes:


As   defined   in   section   3.1,  the  term  declaration  includes  basic
declarations, implicit declarations, and those declarations that  are  part
of   basic   declarations,   for   example,   discriminant   and  parameter
specifications.  It follows from the definition  of  a  declarative  region
that  a  discriminant  specification  occurs  immediately within the region
associated with  the  enclosing  record  type  declaration.   Similarly,  a
parameter  specification  occurs  immediately  within the region associated
with the enclosing subprogram body or accept statement.


The package STANDARD forms a declarative region which encloses all  library
units:   the  implicit declaration of each library unit is assumed to occur
immediately within this package (see sections 8.6 and 10.1.1).


Declarative regions can be nested within other  declarative  regions.   For
example,  subprograms,  packages,  task  units,  generic  units,  and block
statements can be nested within each other, and  can  contain  record  type
declarations, loop statements, and accept statements.


References:   accept  statement 9.5, basic declaration 3.1, block statement
5.6, body stub 10.2, declaration 3.1, discriminant part 3.7.1, discriminant
specification 3.7.1, entry declaration 9.5, formal part 6.1,  generic  body
12.2,   generic  declaration  12.1,  generic  parameter  declaration  12.1,
implicit declaration 3.1, incomplete type declaration 3.8.1,  library  unit
10.1,  loop statement 5.5, package 7, package body 7.1, package declaration
7.1, parameter specification 6.1,  private  type  declaration  7.4,  record
representation  clause  13.4,  record  type  3.7, renaming declaration 8.5,
standard package 8.6, subprogram  body  6.3,  subprogram  declaration  6.1,
subunit 10.2, task body 9.1, task declaration 9.1, task unit 9

8.2  Scope of Declarations


For  each  form of declaration, the language rules define a certain portion
of the program text called the scope of the declaration.  The  scope  of  a
declaration  is  also  called  the  scope  of  any  entity  declared by the
declaration.  Furthermore, if the declaration associates some notation with
a declared entity, this portion of the text is also  called  the  scope  of
this  notation  (either  an  identifier,  a  character literal, an operator
symbol, or the notation for a basic operation).  Within  the  scope  of  an
entity,  and  only  there,  there  are  places where it is legal to use the
associated notation in order to refer to the declared entity.  These places
are defined by the rules of visibility and overloading.


The scope of a declaration that occurs  immediately  within  a  declarative
region  extends  from  the  beginning  of the declaration to the end of the
declarative region;  this part of the scope of a declaration is called  the
immediate  scope.   Furthermore,  for any of the declarations listed below,
the scope of the declaration extends beyond the immediate scope:


(a)  A declaration that occurs immediately within the  visible  part  of  a
     package declaration.


(b)  An entry declaration.


(c)  A component declaration.


(d)  A discriminant specification.


(e)  A parameter specification.


(f)  A generic parameter declaration.


In  each  of  these  cases, the given declaration occurs immediately within
some enclosing declaration, and the scope of the given declaration  extends
to the end of the scope of the enclosing declaration.


In  the  absence  of a subprogram declaration, the subprogram specification
given in the subprogram body or in the body stub acts  as  the  declaration
and rule (e) applies also in such a case.

Note:


The  above scope rules apply to all forms of declaration defined by section
3.1;  in particular, they apply also to implicit  declarations.   Rule  (a)
applies  to a package declaration and thus not to the package specification
of a generic declaration.  For nested declarations, the rules  (a)  through
(f)  apply  at  each level.  For example, if a task unit is declared in the
visible part of a package, the scope of an entry of the task  unit  extends
to  the end of the scope of the task unit, that is, to the end of the scope
of the enclosing package.  The scope of a use clause is defined in  section
8.4.


References:   basic operation 3.3.3, body stub 10.2, character literal 2.5,
component  declaration  3.7,  declaration  3.1,  declarative  region   8.1,
discriminant  specification  3.7.1,  entry  declaration  9.5,  extends 8.1,
generic declaration 12.1, generic parameter  declaration  12.1,  identifier
2.3,  implicit  declaration  3.1,  occur  immediately  within 8.1, operator
symbol  6.1,  overloading  6.6  8.7,  package  declaration   7.1,   package
specification  7.1,  parameter specification 6.1, record type 3.7, renaming
declaration 8.5, subprogram body  6.3,  subprogram  declaration  6.1,  task
declaration  9.1,  task  unit  9,  type  declaration 3.3.1, use clause 8.4,
visibility 8.3, visible part 7.2

8.3  Visibility


The meaning of the occurrence of an identifier at a given place in the text
is defined by the visibility rules and also,  in  the  case  of  overloaded
declarations, by the overloading rules.  The identifiers considered in this
chapter  include  any  identifier  other than a reserved word, an attribute
designator, a pragma identifier, the identifier of a pragma argument, or an
identifier given as a pragma  argument.   The  places  considered  in  this
chapter  are  those where a lexical element (such as an identifier) occurs.
The overloaded declarations  considered  in  this  chapter  are  those  for
subprograms, enumeration literals, and single entries.


For  each  identifier  and  at each place in the text, the visibility rules
determine a set of declarations (with this identifier) that define possible
meanings of an occurrence of the identifier.  A declaration is said  to  be
visible  at  a  given  place  in the text when, according to the visibility
rules, the declaration defines a possible meaning of this occurrence.   Two
cases arise.


  -  The visibility rules determine at most one possible meaning.  In  such
     a   case   the  visibility  rules  are  sufficient  to  determine  the
     declaration defining the meaning of the occurrence of the  identifier,
     or  in  the  absence  of  such  a  declaration,  to determine that the
     occurrence is not legal at the given point.


  -  The visibility rules determine more than  one  possible  meaning.   In
     such a case the occurrence of the identifier is legal at this point if
     and  only  if  exactly  one  visible declaration is acceptable for the
     overloading rules in the given context (see section 6.6 for the  rules
     of  overloading  and  section  8.7  for  the context used for overload
     resolution).


A declaration is only visible within a certain part  of  its  scope;   this
part   starts   at   the  end  of  the  declaration  except  in  a  package
specification, in which case it starts at the reserved word is given  after
the  identifier  of  the  package  specification.   (This  rule applies, in
particular, for implicit declarations.)


Visibility is either by selection or direct.  A declaration is  visible  by
selection at places that are defined as follows.


(a)  For a declaration given in the visible part of a package  declaration:
     at  the  place of the selector after the dot of an expanded name whose
     prefix denotes the package.


(b)  For an entry declaration of a given task type:  at the  place  of  the
     selector  after  the  dot  of  a  selected  component  whose prefix is
     appropriate for the task type.


(c)  For a component declaration of a given record  type  declaration:   at
     the  place of the selector after the dot of a selected component whose
     prefix is appropriate for the type;  also at the place of a  component
     simple  name  (before  the compound delimiter =>) in a named component
     association of an aggregate of the type.


(d)  For a discriminant specification of a given type declaration:  at  the
     same  places  as  for a component declaration;  also at the place of a
     discriminant simple name (before the compound delimiter =>) in a named
     discriminant association of a discriminant constraint for the type.


(e)  For a parameter specification of a given subprogram  specification  or
     entry  declaration:   at the place of the formal parameter (before the
     compound  delimiter  =>)  in  a  named  parameter  association  of   a
     corresponding subprogram or entry call.


(f)  For a generic parameter declaration of a given generic unit:   at  the
     place  of  the generic formal parameter (before the compound delimiter
     =>)  in  a  named  generic  association  of  a  corresponding  generic
     instantiation.


Finally,  within  the  declarative region associated with a construct other
than a record type declaration, any  declaration  that  occurs  immediately
within  the  region  is  visible  by selection at the place of the selector
after the dot of an expanded name whose prefix denotes the construct.


Where it is not visible by selection, a visible declaration is said  to  be
directly  visible.  A declaration is directly visible within a certain part
of its immediate scope;  this part extends to  the  end  of  the  immediate
scope  of  the  declaration,  but  excludes places where the declaration is
hidden  as  explained  below.   In  addition,   a   declaration   occurring
immediately  within  the  visible  part  of  a package can be made directly
visible by means of a use  clause  according  to  the  rules  described  in
section  8.4.   (See also section 8.6 for the visibility of library units.)


A declaration is said to be hidden within (part of)  an  inner  declarative
region  if  the inner region contains a homograph of this declaration;  the
outer declaration is then hidden within the immediate scope  of  the  inner
homograph.  Each of two declarations is said to be a homograph of the other
if  both  declarations  have the same identifier and overloading is allowed
for  at  most  one  of  the  two.   If  overloading  is  allowed  for  both
declarations, then each of the two is a homograph of the other if they have
the  same identifier, operator symbol, or character literal, as well as the
same parameter and result type profile (see 6.6).


Within the specification of a subprogram, every declaration with  the  same
designator  as  the  subprogram is hidden;  the same holds within a generic
instantiation that declares a subprogram, and within an  entry  declaration
or  the formal part of an accept statement;  where hidden in this manner, a
declaration is visible neither by selection  nor directly.


Two declarations that occur immediately within the same declarative  region
must not be homographs, unless either or both of the following requirements
are  met:   (a)  exactly  one  of  them  is  the  implicit declaration of a
predefined operation;  (b) exactly one of them is the implicit  declaration
of  a  derived subprogram.  In such cases, a predefined operation is always
hidden by the other homograph;  a derived  subprogram  hides  a  predefined
operation,  but  is  hidden  by  any other homograph.  Where hidden in this
manner, an implicit declaration is hidden within the entire  scope  of  the
other  declaration  (regardless  of  which  declaration occurs first);  the
implicit declaration is visible neither by selection nor directly.


Whenever a declaration with a certain identifier is visible  from  a  given
point,  the identifier and the declared entity (if any) are also said to be
visible from that point.  Direct visibility and visibility by selection are
likewise defined for character literals and operator symbols.  An  operator
is  directly  visible if and only if the corresponding operator declaration
is directly  visible.   Finally,  the  notation  associated  with  a  basic
operation is directly visible within the entire scope of this operation.


Example:

    procedure P is
       A, B : BOOLEAN;

       procedure Q is
          C : BOOLEAN;
          B : BOOLEAN;  --  an inner homograph of B
       begin
          ...
          B := A;    --  means Q.B := P.A;
          C := P.B;  --  means Q.C := P.B;
       end;
    begin
       ...
       A := B;  --  means P.A := P.B;
    end;

Note on the visibility of library units:


The  visibility of library units is determined by with clauses (see 10.1.1)
and by the fact that library units are implicitly declared in  the  package
STANDARD (see 8.6).

Note on homographs:


The  same  identifier  may  occur in different declarations and may thus be
associated  with  different  entities,  even  if  the   scopes   of   these
declarations  overlap.  Overlap of the scopes of declarations with the same
identifier can result from overloading of subprograms  and  of  enumeration
literals.   Such  overlaps  can also occur for entities declared in package
visible parts and for entries, record  components,  and  parameters,  where
there  is overlap of the scopes of the enclosing package declarations, task
declarations, record type declarations, subprogram  declarations,  renaming
declarations,  or  generic  declarations.   Finally  overlapping scopes can
result from nesting.

Note on immediate scope, hiding, and visibility:


The rules defining immediate scope, hiding, and  visibility  imply  that  a
reference  to  an  identifier within its own declaration is illegal (except
for packages and generic packages).  The identifier hides outer  homographs
within  its  immediate  scope, that is,  from the start of the declaration;
on the other hand, the identifier is visible only  after  the  end  of  the
declaration.    For  this  reason,  all  but  the  last  of  the  following
declarations are illegal:

    K : INTEGER := K * K;              --  illegal
    T : T;                             --  illegal
    procedure P(X : P);                --  illegal
    procedure Q(X : REAL := Q);        --  illegal, even if there is a function named Q
    procedure R(R : REAL);   --  an inner declaration is legal (although confusing)


References:  accept statement 9.5, aggregate 4.3, appropriate  for  a  type
4.1,  argument 2.8, basic operation 3.3.3, character literal 2.5, component
association  4.3,  component  declaration  3.7,  compound  delimiter   2.2,
declaration  3.1,  declarative  region  8.1,  designate  3.8,  discriminant
constraint 3.7.2, discriminant specification 3.7.1, entry call  9.5,  entry
declaration 9.5, entry family 9.5, enumeration literal specification 3.5.1,
expanded name 4.1.3, extends 8.1, formal parameter 6.1, generic association
12.3,  generic  formal  parameter 12.1, generic instantiation 12.3, generic
package  12.1,  generic  parameter  declaration  12.1,  generic  unit   12,
identifier  2.3,  immediate  scope  8.2,  implicit declaration 3.1, lexical
element 2.2, library unit 10.1, object 3.2, occur immediately  within  8.1,
operator  4.5,  operator  symbol  6.1,  overloading  6.6  8.7,  package  7,
parameter 6.2, parameter  association  6.4,  parameter  specification  6.1,
pragma  2.8, program unit 6, record type 3.7, reserved word 2.9, scope 8.2,
selected component 4.1.3, selector 4.1.3, simple name  4.1,  subprogram  6,
subprogram  call  6.4, subprogram declaration 6.1, subprogram specification
6.1, task type 9.1, task unit 9, type  3.3,  type  declaration  3.3.1,  use
clause 8.4, visible part 7.2

8.4  Use Clauses


A  use clause achieves direct visibility of declarations that appear in the
visible parts of named packages.


    use_clause ::= use package_name {, package_name};


For each use clause, there is a certain region of text called the scope  of
the use clause.  This region starts immediately after the use clause.  If a
use  clause  is a declarative item of some declarative region, the scope of
the clause extends to the end of the declarative region.  If a  use  clause
occurs  within a context clause of a compilation unit, the scope of the use
clause extends to the end of the declarative  region  associated  with  the
compilation unit.


In  order to define which declarations are made directly visible at a given
place by use clauses, consider the set of packages named by all use clauses
whose scopes enclose this place, omitting from this set any  packages  that
enclose  this  place.  A declaration that can be made directly visible by a
use clause (a potentially visible  declaration)  is  any  declaration  that
occurs  immediately  within  the  visible  part of a package of the set.  A
potentially visible declaration is actually made directly visible except in
the following two cases:


  -  A potentially visible declaration is not made directly visible if  the
     place  considered  is within the immediate scope of a homograph of the
     declaration.


  -  Potentially visible declarations that have the same identifier are not
     made directly visible unless each of them  is  either  an  enumeration
     literal  specification  or  the  declaration  of  a  subprogram  (by a
     subprogram   declaration,   a   renaming   declaration,   a    generic
     instantiation, or an implicit declaration).


The elaboration of a use clause has no other effect.

Note:


The  above rules guarantee that a declaration that is made directly visible
by a use clause cannot hide an otherwise directly visible declaration.  The
above rules are formulated in terms of the set of  packages  named  by  use
clauses.


Consequently,  the  following  lines  of  text  all  have  the  same effect
(assuming only one package P).

    use P;
    use P; use P, P;


Example of conflicting names in two packages:

    procedure R is
       package TRAFFIC is
          type COLOR is (RED, AMBER, GREEN);
          ...
       end TRAFFIC;

       package WATER_COLORS is
          type COLOR is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
          ...
       end WATER_COLORS;

       use TRAFFIC;       --  COLOR, RED, AMBER, and GREEN are directly visible
       use WATER_COLORS;  --  two homographs of GREEN are directly visible
                          --  but COLOR is no longer directly visible

       subtype LIGHT is TRAFFIC.COLOR;      -- Subtypes are used to resolve
       subtype SHADE is WATER_COLORS.COLOR; -- the conflicting type name COLOR

       SIGNAL : LIGHT;
       PAINT  : SHADE;
    begin
       SIGNAL := GREEN;  --  that of TRAFFIC
       PAINT  := GREEN;  --  that of WATER_COLORS
    end R;


Example of name identification with a use clause:

       package D is
          T, U, V : BOOLEAN;
       end D;

       procedure P is
          package E is
             B, W, V : INTEGER;
          end E;

          procedure Q is
             T, X : REAL;
             use D, E;
          begin
             --  the name T means Q.T, not D.T
             --  the name U means D.U
             --  the name B means E.B
             --  the name W means E.W
             --  the name X means Q.X
             --  the name V is illegal : either D.V or E.V must be used
             ...
          end Q;
       begin
          ...
       end P;


References:  compilation unit 10.1, context clause 10.1,  declaration  3.1,
declarative  item  3.9,  declarative  region  8.1,  direct  visibility 8.3,
elaboration 3.1 3.9, elaboration  has  no  other  effect  3.1,  enumeration
literal  specification  3.5.1,  extends  8.1,  hiding  8.3,  homograph 8.3,
identifier 2.3, immediate scope 8.2, name  4.1,  occur  immediately  within
8.1, package 7, scope 8.2, subprogram declaration 6.1, visible part 7.2

8.5  Renaming Declarations


A renaming declaration declares another name for an entity.


    renaming_declaration ::=
         identifier : type_mark   renames object_name;
       | identifier : exception   renames exception_name;
       | package identifier       renames package_name;
       | subprogram_specification renames subprogram_or_entry_name;


The  elaboration  of a renaming declaration evaluates the name that follows
the reserved word renames and thereby determines the entity denoted by this
name (the renamed entity).  At any point where a  renaming  declaration  is
visible, the identifier, or operator symbol of this declaration denotes the
renamed entity.


The first form of renaming declaration is used for the renaming of objects.
The  renamed  entity  must  be an object of the base type of the type mark.
The properties of the renamed object  are  not  affected  by  the  renaming
declaration.   In particular, its value and whether or not it is a constant
are unaffected;  similarly, the constraints that apply to an object are not
affected by renaming (any constraint  implied  by  the  type  mark  of  the
renaming  declaration  is ignored).  The renaming declaration is legal only
if exactly one object has this type and can be denoted by the object  name.


The  following  restrictions  apply  to the renaming of a subcomponent that
depends on discriminants of a variable.  The renaming is not allowed if the
subtype of the variable, as defined in a corresponding object  declaration,
component declaration, or component subtype indication, is an unconstrained
type;   or  if  the  variable  is a generic formal object (of mode in out).
Similarly if the variable is  a  formal  parameter,  the  renaming  is  not
allowed  if  the  type mark given in the parameter specification denotes an
unconstrained type whose discriminants have default expressions.


The second form of  renaming  declaration  is  used  for  the  renaming  of
exceptions;  the third form, for the renaming of packages.


The  last  form  of  renaming  declaration  is  used  for  the  renaming of
subprograms  and  entries.   The  renamed  subprogram  or  entry  and   the
subprogram  specification  given  in the renaming declaration must have the
same parameter and result type profile (see 6.6).  The renaming declaration
is legal only if exactly one visible  subprogram  or  entry  satisfies  the
above  requirements  and  can  be  denoted by the given subprogram or entry
name.  In addition, parameter modes must be identical for formal parameters
that are at the same parameter position.


The subtypes of the parameters and result (if any) of a renamed  subprogram
or  entry  are not affected by renaming.  These subtypes are those given in
the  original  subprogram  declaration,  generic  instantiation,  or  entry
declaration  (not  those of the renaming declaration);  even for calls that
use the new name.  On the other hand, a renaming declaration can  introduce
parameter  names  and  default  expressions  that  differ from those of the
renamed subprogram;  named associations of calls with  the  new  subprogram
name  must  use the new parameter name;  calls with the old subprogram name
must use the old parameter names.


A procedure can only be renamed as a procedure.  Either of  a  function  or
operator  can be renamed as either of a function or operator;  for renaming
as  an  operator,  the  subprogram  specification  given  in  the  renaming
declaration  is  subject  to  the  rules  given in section 6.7 for operator
declarations.   Enumeration  literals  can   be   renamed   as   functions;
similarly,  attributes  defined as functions (such as SUCC and PRED) can be
renamed as functions.  An entry can only be renamed as  a  procedure;   the
new name is only allowed to appear in contexts that allow a procedure name.
An  entry of a family can be renamed, but an entry family cannot be renamed
as a whole.


Examples:

    declare
       L : PERSON renames LEFTMOST_PERSON; -- see 3.8.1
    begin
       L.AGE := L.AGE + 1;
    end;

    FULL : exception renames TABLE_MANAGER.TABLE_FULL; -- see 7.5

    package TM renames TABLE_MANAGER;

    function REAL_PLUS(LEFT, RIGHT : REAL   ) return REAL    renames "+";
    function INT_PLUS (LEFT, RIGHT : INTEGER) return INTEGER renames "+";

    function ROUGE return COLOR renames RED;  --  see 3.5.1
    function ROT   return COLOR renames RED;
    function ROSSO return COLOR renames ROUGE;

    function NEXT(X : COLOR) return COLOR renames COLOR'SUCC; -- see 3.5.5


Example of a renaming declaration with new parameter names:

    function "*" (X,Y : VECTOR) return REAL renames DOT_PRODUCT; -- see 6.1


Example of a renaming declaration with a new default expression:

    function MINIMUM(L : LINK := HEAD) return CELL renames MIN_CELL; -- see 6.1

Notes:


Renaming may be used to resolve name conflicts and to act as  a  shorthand.
Renaming  with  a different identifier or operator symbol does not hide the
old name;  the new name and the old name need not be visible  at  the  same
points.    The   attributes  POS  and  VAL  cannot  be  renamed  since  the
corresponding specifications cannot be written;  the  same  holds  for  the
predefined multiplying operators with a universal_fixed result.


Calls  with  the  new name of a renamed entry are procedure call statements
and are not allowed at places where  the  syntax  requires  an  entry  call
statement  in  conditional  and  timed  entry  calls;  similarly, the COUNT
attribute is not available for the new name.


A task object that is declared by an object declaration can be  renamed  as
an   object.    However,   a  single  task  cannot  be  renamed  since  the
corresponding task type is anonymous.  For similar reasons, an object of an
anonymous array type cannot be  renamed.   No  syntactic  form  exists  for
renaming a generic unit.


A subtype can be used to achieve the effect of renaming a type (including a
task type) as in

    subtype MODE is TEXT_IO.FILE_MODE;


References:   allow  1.6, attribute 4.1.4, base type 3.3, conditional entry
call 9.7.2,  constant  3.2.1,  constrained  subtype  3.3,  constraint  3.3,
declaration  3.1,  default  expression 6.1, depend on a discriminant 3.7.1,
discriminant 3.7.1, elaboration 3.1 3.9, entry 9.5, entry call  9.5,  entry
call  statement  9.5,  entry declaration 9.5, entry family 9.5, enumeration
literal 3.5.1, evaluation of a name 4.1,  exception  11,  formal  parameter
6.1,  function  6.5,  identifier 2.3, legal 1.6, mode 6.1, name 4.1, object
3.2, object  declaration  3.2,  operator  6.7,  operator  declaration  6.7,
operator symbol 6.1, package 7, parameter 6.2, parameter specification 6.1,
procedure   6.1,   procedure   call   statement  6.4,  reserved  word  2.9,
subcomponent 3.3, subprogram 6, subprogram call 6.4, subprogram declaration
6.1, subprogram specification 6.1, subtype 3.3.2, task  object  9.2,  timed
entry call 9.7.3, type 3.3, type mark 3.3.2, variable 3.2.1, visibility 8.3

8.6  The Package Standard


The predefined types (for example the types BOOLEAN, CHARACTER and INTEGER)
are  the  types  that are declared in a predefined package called STANDARD;
this package also includes the declarations of their predefined operations.
The package STANDARD is described in Annex C.  Apart  from  the  predefined
numeric  types,  the specification of the package STANDARD must be the same
for all implementations of the language.


The package STANDARD  forms  a  declarative  region  which  encloses  every
library  unit  and consequently the main program;  the declaration of every
library unit is assumed to occur  immediately  within  this  package.   The
implicit  declarations of library units are assumed to be ordered in such a
way that the scope of a given library unit includes  any  compilation  unit
that  mentions  the given library unit in a with clause.  However, the only
library units that are visible within  a  given  compilation  unit  are  as
follows:   they  include  the  library units named by all with clauses that
apply to the given unit, and moreover, if the given  unit  is  a  secondary
unit of some library unit, they include this library unit.

Notes:


If  all  block  statements  of  a  program are named, then the name of each
program unit can always be  written  as  an  expanded  name  starting  with
STANDARD (unless this package is itself hidden).


If  a type is declared in the visible part of a library package, then it is
a consequence of the visibility rules  that  a  basic  operation  (such  as
assignment)  for  this  type  is  directly visible at places where the type
itself is not visible (whether by selection  or  directly).   However  this
operation  can  only  be  applied  to  operands  that  are  visible and the
declaration of these operands requires the visibility of either the type or
one of its subtypes.


References:  applicable with clause 10.1.1, block name 5.6, block statement
5.6, declaration 3.1, declarative region 8.1, expanded name  4.1.3,  hiding
8.3,  identifier  2.3,  implicit  declaration  3.1, library unit 10.1, loop
statement 5.5, main program 10.1, must 1.6,  name  4.1,  occur  immediately
within  8.1,  operator 6.7, package 7, program unit 6, secondary unit 10.1,
subtype 3.3, type 3.3, visibility 8.3, with clause 10.1.1

8.7  The Context of Overload Resolution


Overloading is defined for subprograms,  enumeration  literals,  operators,
and  single  entries,  and  also  for  the  operations that are inherent in
several basic operations such as assignment, membership tests,  allocators,
the literal null, aggregates, and string literals.


For  overloaded entities, overload resolution determines the actual meaning
that an occurrence of an identifier has, whenever the visibility rules have
determined that more than one meaning is acceptable at the  place  of  this
occurrence;   overload resolution likewise determines the actual meaning of
an occurrence of an operator or some basic operation.


At such a place all visible declarations are considered.  The occurrence is
only legal if there is exactly one interpretation of  each  constituent  of
the  innermost  complete  context;   a  complete  context  is  one  of  the
following:


  -  A declaration.


  -  A statement.


  -  A representation clause.


When considering possible interpretations of a complete context,  the  only
rules  considered are the syntax rules, the scope and visibility rules, and
the rules of the form described below.


(a)  Any rule that requires a name or expression to have a certain type, or
     to have the same type as another name or expression.


(b)  Any rule that requires the type of a name or expression to be  a  type
     of  a certain class;  similarly, any rule that requires a certain type
     to be a discrete, integer, real,  universal,  character,  boolean,  or
     nonlimited type.


(c)  Any rule that requires a prefix to be appropriate for a certain  type.


(d)  Any rule that specifies a certain type as the result type of  a  basic
     operation,  and any rule that specifies that this type is of a certain
     class.


(e)  The rules that require the type of an aggregate or string  literal  to
     be  determinable  solely  from the enclosing complete context (see 4.3
     and 4.2).  Similarly, the rules that require the type of the prefix of
     an attribute, the type of the expression of a case statement,  or  the
     type  of  the  operand  of  a  type  conversion,  to  be  determinable
     independently of the context (see 4.1.4, 5.4, 4.6, and 6.4.1).


(f)  The rules given in section  6.6,  for  the  resolution  of  overloaded
     subprogram  calls;   in  section  4.6, for the implicit conversions of
     universal expressions;  in section 3.6.1, for  the  interpretation  of
     discrete  ranges  with bounds having a universal type;  and in section
     4.1.3, for the interpretation of an expanded name whose prefix denotes
     a subprogram or an accept statement.


Subprogram names used as pragma arguments follow  a  different  rule:   the
pragma can apply to several overloaded subprograms, as explained in section
6.3.2  for  the pragma INLINE, in section 11.7 for the pragma SUPPRESS, and
in section 13.9 for the pragma INTERFACE.


Similarly, the simple names given in context clauses (see  10.1.1)  and  in
address clauses (see 13.5) follow different rules.

Notes:


If  there  is  only one possible interpretation, the identifier denotes the
corresponding entity.  However, this does not mean that the  occurrence  is
necessarily  legal  since other requirements exist which are not considered
for overload resolution;  for example,  the  fact  that  an  expression  is
static,  the  parameter  modes,  whether an object is constant, conformance
rules,  forcing  occurrences  for  a  representation   clause,   order   of
elaboration, and so on.


Similarly,  subtypes  are  not  considered  for  overload  resolution  (the
violation of a constraint does not make a program  illegal  but  raises  an
exception during program execution).


Rules that require certain constructs to have the same parameter and result
type  profile  fall  under the category (a);  the same holds for rules that
require conformance of  two  constructs  since  conformance  requires  that
corresponding  names  be  given  the  same  meaning  by  the visibility and
overloading rules.


A loop parameter specification is  a  declaration,  and  hence  a  complete
context.


References:   aggregate 4.3, allocator 4.8, assignment 5.2, basic operation
3.3.3, case statement 5.4, class of type 3.3, declaration 3.1,  entry  9.5,
enumeration  literal  3.5.1, exception 11, expression 4.4, formal part 6.1,
identifier 2.3, legal 1.6, literal 4.2, loop parameter  specification  5.5,
membership  test  4.5.2,  name  4.1,  null  literal  3.8,  operation 3.3.3,
operator 4.5, overloading 6.6,  pragma  2.8,  representation  clause  13.1,
statement  5,  static  expression  4.9,  static  subtype 4.9, subprogram 6,
subtype 3.3, type conversion 4.6, visibility 8.3


Rules of the form (a):  address clause 13.5, assignment 5.2,  choice  3.7.3
4.3.2  5.4,  component  association  4.3.1  4.3.2,  conformance  rules 9.5,
default expression 3.7 3.7.1 6.1  12.1.1,  delay  statement  9.6,  discrete
range   3.6.1   5.5   9.5,   discriminant   constraint  3.7.2,  enumeration
representation clause 13.3, generic  parameter  association  12.3.1,  index
constraint  3.6.1,  index  expression 4.1.1 4.1.2 9.5, initial value 3.2.1,
membership test 4.5.2, parameter association 6.4.1,  parameter  and  result
type  profile  8.5  12.3.6, qualified expression 4.7, range constraint 3.5,
renaming of an object 8.5, result expression 5.8


Rules of  the  form  (b):   abort  statement  9.10,  assignment  5.2,  case
expression  5.4, condition 5.3 5.5 5.7 9.7.1, discrete range 3.6.1 5.5 9.5,
fixed point type declaration 3.5.9, floating point type declaration  3.5.7,
integer  type  declaration  3.5.4, length clause 13.2, membership test 4.4,
number declaration  3.2.2,  record  representation  clause  13.4,  selected
component 4.1.3, short-circuit control form 4.4, val attribute 3.5.5


Rules  of the form (c):  indexed component 4.1.1, selected component 4.1.3,
slice 4.1.2


Rules of the form (d):  aggregate 4.3, allocator 4.8, membership test  4.4,
null  literal  4.2,  numeric  literal  2.4, short-circuit control form 4.4,
string literal 4.2